An increasing number of Internet Application Service Providers (ASP's) are providing services over the internet which make use of user location information to provide customised information to each user, based on that user's present location.
Typical of such services are those which request location information from the user and subsequently present web pages to that user, based on the user's location. For example, a user may view a pizza restaurant chain's home page, which requests details of his location; the user enters and sends the details; and the user is then presented with a web page containing details of the branch of the chain nearest the user's stated location.
A problem with this method is that where any one user wishes to access multiple such services, he is required to re-enter substantially the same location details for each such service used, since the location information provided to one service provider is unavailable to another. Furthermore, the level of granularity of the location information may vary markedly between services: one service provider may request the information in the form of a postal address code whilst another may request it simply in the form of the name of the nearest town; some services may require only an indication of the country in which the user is located.
At present, known mechanisms available to ASP's to customise the information presented to the end user for their locality is either (a) fine grained but based on customer interaction, (b) coarser-grained and based on Internet domain names, which are at best country-specific, or (c) based on Classless Internet Domain Routing (CIDR) routing blocks which are continent—and ISP—specific.
To mitigate the effects of multiple data re-entry, one known approach is to store location details already provided to one such service in a “cookie” on the user computer. Subsequent accesses to the same service can access the cookie and extract the location information automatically without further user intervention.
Problems still remain with this approach. It does not address the problem of having to re-enter location information to disparate services, at least on the first use of each of those services. Nor does it take account of the user changing location between accesses to the same service (for example by accessing the internet over a mobile network, or by having moved home): in neither of these cases does historic location information necessarily represent the user's present location, and further location re-entry is required.
Another known approach is to modify the service provider's response based on the domain name, IP address, preferred language, or other content negotiations when receiving the initial web request.
A problem with these approaches is that none of them provide fine-grained location information to the ASP, and all impose considerable complexity on each application.
There already are telephony techniques for deriving locations both to support the Emergency Services and also “Intelligent Network” call routing, for example where a National low call number is routed to the appropriate franchisee for the area the call comes from.
There are also emerging standards for accessing locations of Cellular Phones, with a legislative requirement that the call can be located to within 100m. WAP phones can be interrogated as to their current cell (or group of cells), and recent press announcements demonstrate the existence of technologies for specialised WAP location based service.
Additionally there is work in the Internet Engineering Technology Forum (IETF) on a Spatial Location Service, with emphasis on discovery, authentication, trust and verification. For example, the draft contribution “ISL Architectural Considerations” proposes definitions of a new service, requiring creation and use of location agents and/or proxies. Implementation of such an arrangement is potentially complex and makes little, if any, use of existing infrastructure.